intro words

\section{Filtering}

two different types of filtering used by ISPs to thwat illegal and copyright-infindging content by ISPs: via DNS only or via DNS and forwarding plane filtering. using reference point towards which pings are sent in addition to the supposable filtered resource enables testing for the presence of both DNS and/or IGP filtering...



\subsection{bogon filtering}

initially debognising only done via BGP beacons (http://www.ripe.net/ripe/docs/ripe-351), now atlas is possible as well.

When de-bogonising address space, we have traditionally only looked at the routing plane. We have asked ourselves "How many Routing Information Service (RIS) peers are advertising a route?" We have also provided pingable targets so that each of you could check your own data plane connectivity and answer the question "Can I actually get packets to this address space and back?". However, we were unable to measure the data plane continuously and answer the question "How many ASes or prefixes can actually get packets to this address space?"

two types of filtering examined: bogon and filtering of illegitimate resources
ripe ncc has been examining debogonised prefixes such as 128/8 initially only via BGP. with the advent of ripe atlas in 2011 a debogonising project started that used ripe atlast to constantly monitor the subnet from 100 probes. this effort ended in jul 2012. last such measurement is in feb. 2013. other debogonised prefixes have not been studied, namely (via debogon firefox)



#-------------------------
#--------------------------
#TOOD:
- probe ID 4613 from reference chunk 1 is an example of a probe that did pings but went down

#--------------------------



128.0.0.0/16   -->128.0.144.145 ripe-test.my-wire.de.
185.1.0.0/21  IPF - IP Fjarskipti ehf(07/12) -->185.1.1.1/24 pri.authdns.ripe.net. dns.ripe.net. 1390924798 3600 600 864000 7200
185.24.0.0/24  -->185.24.0.1/24 pri.authdns.ripe.net. dns.ripe.net. 1390924798 3600 600 864000 7200

Experiment points:
    - filtering
        ping
        timeout values    


reference point selection
-------------------------

probe selection
-----------------
different prefixes, therefore AS overlap, 
no probes from prefixes belonging to RIPE NCCs ASNs
in total x num of probes were used (count GUI msm provided probes.). msms issued in chunks of <500 due to UDM limitations 
ls -la
graph2
--------------------------
what were the latencies of failing pings and could it be that they've failed because of just timing out instead of not being routable

0. dataset description
    - ping results
    - compared to reserved dataset may have a subset of probes
        - probe ID
        - reserved live probes may have a no result yet message: study this! they're not part of the resulting dataset
    - probes that went down during the test, but have returned ping results ARE PART of it
    - what was done with high RTT?? what i did is to just leave it in.
1. Results dropped from the dataset:
    A. Such which have 
        - probes which werent reseved due to probems (Default filtered out by RIPE system)
        - probes that shut down during the testing (Default filtered out by RIPE system)
            - such are considered if they've returned something
        - live probes that havent returned anything (Default filtered out by RIPE system)
        - probes whose network default gateway went down {u'error': u'sendto failed: Network is unreachable'}
    B. Intermittent results - in case a ping to the debogon succeeded in an hour, or 
       the control point, it remains in the dataset
2. Use cases
    A. Debogon reachable, but control point ureachable: CONSIDERED
    B. Debogon ureachable, but control point reachable
        - reference reachable, but with RTT>(calculate value), ====> further study via TRACEROUTE
        - reference reachable with RTT<(calculated value) ================> FILTERING
3. Observations of raw data:
    * situations in which 2.B is observed might be only present during portions of pings. there
      might be intermittent reachability due to changes in underlying packet routing. this
      implies that one of the used routes takes a route in which filtering occurs at some point.
      
filtering
---------

considered properties:
- only results from probes that were able to ping both the control point and the bogon.


discarded measurements from dataset
-----------------------------------
- empty results
    
- both the control point and the bogon cannot be reached
- both the control point and the bogon have no report yet, or the probes are considered as down. in case both dot have any result what
- 
- if bogon reachable, but reference unreachable, nothing
-  


TPB test
---------------------
-------------------------
-------------------------

reference poing: ns1.resilans.se - 194.14.3.53

reference point should be from AS50066 Serious Tubes Networks (upstream?) (http://en.wikipedia.org/wiki/Serious_Tubes_Networks) 


Greenpeace from russia? after the incident with the oil rig in september - http://en.wikipedia.org/wiki/Greenpeace_Arctic_Sunrise_ship_case
----------------------------------
IP investigation: 194.0.197.79 seems to be the same all over the world after doing a DNS IN A request from 500 probes in different countries
AS investigation: AS16265 LEASEWEB B.V.  
Reference point: 85.17.100.226 - po100.sr1.evo.leaseweb.net
------------------------------------------------

FB, Twitter

- china blocked?
- egypt?
- iran



\subsection{Content filtering}

\section{prefix hikacking}

\section{Atlas }
